perm filename DOC.RLL[RDG,DBL]6 blob
sn#611576 filedate 1981-09-14 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00007 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 Auxillary functions - Really in CORLL
C00006 00003 RLL-OPEN( kbname params )
C00012 00004 Comments re: AAAI Paper
C00015 00005 ∂28-May-81 2122 BIS hpp-80-9
C00017 00006 ∂TO MASINTER@PARC (CC CSD.SMITH) 13:35 15-Jul
C00034 00007 ∂13-Sep-81 1626 GREINER at RAND-AI WHy some infinite loops are harmless:
C00040 ENDMK
C⊗;
Auxillary functions - Really in CORLL
RETRIEVE[ names kb noclose? ]
This function is designed to (non-destructively) retreive
one or more units from a knowledge base. Note this kb may be one of the
knowledge bases currently open - in which case, the values returned will
be the property/value pairs of U before this session started.
names - Should be the list of unit names desired. [A single atom
is acceptable as well.]
kb - This should be the KB on which each member of names is stored.
[If it is not of the form xxx.KB, the ".KB" will be tacked on.]
If omitted, will use the KB associated with the first member
of names if that unit is in a currently open KB, or will ask
user for KB name.
noclose?- If NIL, will close the KB when done.
The value returned be a list whose members are of the form
(unit-name . (p1 v1 p2 v2 ... pN vN))
where unit-name is the name unit, and the pi's and vi's are the properties
and their corresponding values, respectively.
NOTE: if unable to find unit-name, the CDR of this list will be the atom
"*** Trouble -- unable to find ***"
(Various other error conditions may be encountered - eg if the file could
not be found, or opened; or if it was not in a format CORLL would find
acceptable (ie first position holding the pointer to the unit index.)
ReportAll[ filename ]
This should be used to report all the modifications made to any
unit during this session. These are written onto the file filename.
(If ReportAll is called with no arguments, the user will be asked to
supply the file name. Returning NIL, ) or ] will cause UP.REPORT to
be used. In any case, the file used will be the value of
the global variable UP.REPORTINGFILE.)
This is done by advising all the functions stored on the global UA.WRITINGFNS.
Notice this will significantly slow down the system.
Diagnose[ kb ]
This function will check the knowledge base kb for syntactic
consistency. After putting all units, it reads through each unit, to confirm
that its entry is a list with an even number of values, and that every location
in the file is assigned to exactly one unit, or the free block list.
Warning messages are reported whenever a hole in encountered.
If more than one "thing" claims some space, an error message is printed,
and the name of the first unit involved is stored on the list this function
returns. [Note that this function returned NIL if no errors are encountered.]
Finally, this function will print a "." every 50 units it scans.
RLL-OPEN( kbname params )
This opens the Knowledge Base, kbname, and does all sorts of other stuff.
"kbname" can be the simple description (eg RLL),
or full file name (as <CSD.RLL>EURISKO.KB.3), or anything inbetween.
"params" is a list of the form
(readwrite? (initializingfn? . args))
where both "readwrite?" and "initializingfn?" ε {Y N NIL},
and "args" is arbitrary. (This is passed to the initialization function.)
[Here and below the value of Y means do this action, N means do NOT perform
it, and NIL means to ask the user, when necessary, what to do.]
RLL-WRITE( kbname params )
This does the work necessary to close the Knowledge Base, kbname.
"kbname" is as above;
"params" is a list of the form
( (finishingfn? . args) )
where "finishingfn?" ε {Y N NIL}, and "args" is passed to the
finishing function (that is, the function whose name is stored on
the Status unit of the is KB - eg HEURS.STATUS)
RLL-SYSOUT( sysoutname params )
This preserves the state of the system, in an EXE file.
"sysoutname" is the value passed to SYSOUT.
"params" is a list
(CopyNow? NoLogout? CopyOnReturn? OpenAsIs?)
where both "CopyNow?" and "CopyOnReturn?" are one of {Y N NIL} or a list
of currently opened KBs, or descriptors thereof,
"NoLogout?" ε {Y N NIL}, and "OpenAsIs?" is Y, N, NIL, BOTH, INPUT,
or a list of elements (kbname . access), where "kbname" is a to be
opened knowledge base, and "access" ε {Y BOTH INPUT}, where the value
Y means to open this KB in whatever mode it had been.
Standard Functions, defaulted to RLL-1's knowledge bases:
StandardStartUp( kbname params )
This initializes the Knowledge Base, kbname.
"kbname" is as above.
"params" is a list of the form
(readfiles? (open-superiorKBs? use-same-args?) reconnect-if-necessary?)
where "readfiles?", "open-superiorKBs?" and "reconnect-if-necessary?" ε
{Y N NIL} (following conventions mentioned above).
If true, readfiles? means load in the files located on the ? slot of the kb's
status unit; open-superiorKBs? means to open the networks which are
necessary for this kb (these are stored on the Networks slot of that unit),
and reconnect-if-necessary? means the inverse links of this kb's units
should be readded, if there is some kb which appears unconnected with this kb.
If "use-same-args?" is Y the same list of arguments will used when opening
these superior kbs.
≡≡≡≡ ↑ This doesn't work ≡≡≡≡
StandardFinishUp( kbname params )
This does the final work requires to close the Knowledge Base, kbname.
"kbname" is as above.
"params" is a list of the form
(remove-virtual-slots? disconnect-from-otherKBs? diagnose? (makefile? . args))
where "remove-virtual-slots?", "disconnect-from-otherKBs?", "diagnose?"
and makefile? ε {Y N NIL}.
If true, "remove-virtual-slots?" will remove the virtual slots of all the
units of the kb; "disconnect-from-otherKBs?" means to remove inverse links,
stored on OTHER (now open) knowledge bases which refer to units in this one;
"diagnose?" will check this kb for syntactic accuracy, and "makefile?" tells
the system to MAKEFILE over each associated file. That command will also
be passed "args" (eg (RC STF)) as a second argument.
Comments re: AAAI Paper
Date: 18 May 1980 1603-PDT
From: CSD.LENAT
Subject: AAAI Papers
To: CSD.GREINER
Very few were accepted (about one in four), including only some of the
program committee's papers. Ours was accepted, however, in the "clearly
accept" category, of which there were surprisingly few examples. Most
of the ones we finally accepted were originally calssified "good but not great".
I neglected to find out about (and didn't review) any other "local" papers,
so I don't know how Dave, Mike, etc. fared. Brachman's repr. paper was
rejected (he was on the committee, incidentally) as insubstantive. The
experience was a good one, overall; we got everything done in about 9
solid hours of work. Woody Bledsoe will be staying over to meet with me
some tomorrow; I'll look around for you if you're interested.
Doug
-------
Mailed to LENAT@SUMEX (CC Hazen) 17:23 26-June
Doug:
A copy of the paper was put in your mailbox, identical to the one on
Marion's desk. (Yes, both have lines drawn in...)
If you want to change the document, you'll probably want to use the
Window Edge command, typing (to Bravo) "WE10<esc>" -- this moves the screen
over to see the text.
(The file is <GREINER>RLL>AAAI1.BRAVO -- same password as usual.
Note the AAAI.BRAVO paper has NOT been kept up to date with the corrections.)
Things to consider deleting, if space gets tight:
1. Subtitles
2. Whole Mary example - its more trouble than its worth, especially as it's wrong.
3. Semantics part -- especially the footnote. (Not that it's uninterested, but at
$100/page, ....)
4. Part of the applications - where we assert that xxx is considering using RLL.
[We should add in Larry's eventual work, don't you think?]
I might meander it in the afternoon --
Russ
∂28-May-81 2122 BIS hpp-80-9
Just finished reading this informative paper. I found the following
mis-prints, which you may want to correct for future printings.
p 4 `designing expert systems' for `designing expert system'
p 4 `how RLL-1 fits' for `how RLL-1 fit'
p 6 `distinguish' for `distinquish'
p 17 `expedient' for `expediant'
p 19 `axiomatized' for `axiomitized'
p 20 `equivalent' for `equalivalent'
p 20 `can always fall' for `can always falls'
p 21 `malleability' for `mallibility'
p 22 `is as unbiased' for `is not as unbiased'
p 22 `environment' for `enviroment'
p 23 `malleable' for `mallible'
? p 23 `quantitatively' for `quantatively'
p 24 `maintenance' for `maintanence' (twice)
p 24 `to aid in' for `to aide in'
p 27 line 18 is missing a final `)'
p 27 line 21 is missing a final `)'
---
∂To BIS 14:02 29-May
Danke
Glad you enjoyed it. Those changes have been made. Any other alterations,
at any level? (perhaps at a more semantic level?)
Thanks for you comments...
Russ
∂TO MASINTER@PARC (CC CSD.SMITH) 13:35 15-Jul
Wow - such fast response!
Larry:
Some comments on your comments:
0) Did you peruse both XUTIL and XUTILM. Both have nice goodies Dave and
I have assembled -- often after finding that both of us (and no doubt other
users as well) had independently written isomorphic code for the same
type of task.
By the way, I assume you are aware of Bill vanMelle's goldmine, in WW.
1) our friend BACKQUOTE
We have four flavors of the beast:
(BACKQUOTE form vals fn) - evaluates all three args. Any occurance of ,1 in
(the evaluation of) form is replaced by (CAR vals), ,2 is replaced
by (CAR (NTH vals 2)), etc. (IE the value of (CAR (NTH vals i)) replaces
each ,i -- and the value is spliced in for ",@i"s)
Of course the usual ,expr is evaluated, as happens in all variants
of backquotes.
Now for other bells and whistles:
i) Maybe you didn't really want to EVALuate the ,expr occurring within
form - but really wanted to hand this to some arbitrary function.
It is the value of that function call which is then
CONSed (or APPENDed) into the unevaluated surrounding parts of
the overall expression.
This arbitrary function is the third argument passed, which
defaults to EVAL if omitted...
Note it's a bit confusing what to do with ,1 type of things in this case.
As vals is already evaluated, there is no easy way to first
unevaluate its CAR, and then apply fn to that value.
So what we do is use the value of (APPLY* fn (CAR (NTH vals i))).
In practice, I never use both vals and fn. (Actually, I never
bother to use vals.)
ii) It turns out I needed to have nested BACKQUOTEs -- which means I wanted
the outer form to return things which still had ,s in them.
Hence the ,'expr -- which expands to ,expr.
(BACKQUOTEQ form vals fn) - Just like BACKQUOTE, but leaves form unevaluated.
(BACKQUOTE* form val1 val2 ... valN) - This is similar to BACKQUOTE, but here each
,i is replaced with vali, rather than that (CAR (NTH vals i)).
Note one cannot use the optional function here.
(BACKQUOTEQ* form val1 val2 ... valN) - This has evolved to be the standard
form. It is just like BACKQUOTE*, except that form is passed unevaluated.
There is also a macro for this last BACKQUOTEQ* form, which expands into the
desired set of CONSes and APPENDs. As a fringe benefit, it will only
evaluate the ,1 ... once -- so
(BACKQUOTEQ* (,1 ,1) (GENSYM))
expands into
((LAMBDA (A1) (LIST A1 A1))
(GENSYM))
and NOT
(LIST (GENSYM) (GENSYM))
[Note one can still get that latter form by typing
(BACKQUOTEQ* (,(GENSYM) ,(GENSYM)))
]
I agree with you - having a , readmacro would be a win -- especially when PPing
the forms. [Seeing things like
(BACKQUOTEQ* (foo fred
,
(CAR dog)))
is very annoying.]
I didn't know about such read- and pp- macros when I was (re)writing
those functions.
You may have noticed a great deal of the complexity of these functions
(well, of BACKQUOTEL and BQFN, the unseen workhorses for these schenanigans)
is in handling both
,dog
and
, (CAR frog)
-- which had to be done independently.
Is the solution to have ,dog to expand to (UNBQ dog), ,@dog into (UNBQ @ dog)?
I think this would obviate the need to have the ,'dog things - yes?
Anyway, perhaps someone with time could fix up the code -- I will if I get
the chance; eventually...
2) I'm the culprit responsible for the DRIBBLE stuff.
It seems the dribble file isn't closed when the system crashes -- and hence
it is lost those times you need it most.
So it hacked up the stuff in DRIBBLECOMS, which essentially re-opens the
dribblefile every 25 user commands. (That constant is the value of some variable
whose name I forget.)
Anyway, I since added a bunch of other user DRIBBLE related stuff -
like the advise to LOGOUT which closes the file, and on the various
____SYSOUTFORMS.
Doing this I realized some other incompletenesses of IL: eg that it was
impossible to selectively unadvise a function. Hence that function.
3) The -DO macros basically simulate what the MACLISP DO function does.
The various flavors indicate how precise (and expensive) the match is.
EG the plain -DO doesn't worry about evaluating the forms at once.
4) What is "NIH"? (Noway In Hell was proposed, and National Institute of Health
was quickly rejected.)
5) Yes - your PSETQ* was obscure. In what way is it more efficient that
Dave's code?
6) By the way, the file [Rand-Ai]<GREINER.RLL>UTIL has other potentially useful
general goodies, intermingled with many specific-to-my-task functions.
For example, I'm queried where to keep each function as soon as it is created,
thanks to advice to /PUTD, /MOVD and friends.
Let me know if you want to be burdened with those "features".
Thanks,
Russ
∂15-Jul-81 1531 Masinter at PARC-MAXC Re: Wow - such fast response!
In-reply-to: RDG's message of 15 Jul 1981 1335-PDT
To: Russell Greiner <RDG at SU-AI>
cc: masinter, csd.smith at SU-SCORE
(1) I wanted an example where all of the hair in BACKQUOTE was useful.
Given the amount of cruft already in Interlisp, I'm reluctant to add a lot of hair
to a facility if a hairless version is as useful in 90% of the cases. Your answer
leads me to believe that the simpler one I did (which I intend to include in the
"standard" release) is in fact useful in 90% of the cases.
(2) Why don't you hook in your DRIBBLEFILE stuff into the IOWAITDAEMON?
Better than some arbitrary count on events.
(3) you still didn't answer why you didn't use the iteratives which are already
there... Do you dislike them, or just the documentation? (I'm thinking about the
next revision to the manual)
(4) NIH = Not Invented Here: the major reason for reimplementing something that
was already done by somebody else....
(5) Perhaps I didn't understand the way that PSETQ* translated, but it seemed
like my version would not do any conses while Dave's code would, every time
you did an assignment.
(6) The "right" way to handle querying where to put a function as soon as it is
created is to hook in a WHENCHANGED property for the filepackagetype (cf. p
14.73.) E.g. (FILEPKGTYPE 'FNS 'WHENCHANGED '(FINDPLACEFORITEM))
and (FINDPLACEFORITEM (NAME TYPE NEWFLG)
(if (NOT (WHEREIS NAME TYPE)) then (FILES?)]
About packages in general: people are free to put packages with documentation,
on the <NetLispUsers> directory at PARC (login ANONYMOUS yourname). A
general "utility" file isn't really appropriate, but rather something which can be
separately documented and or loaded is. vanMelle has been reluctant to publish
his stuff, because he doesn't want folks to bug him, I guess. (I don't want folks
to bug him too much, either, I suppose.) Do you want folks to bug you?
Larry
∂TO MASINTER@Parc, CSD.SMITH@Score 16:06 20-Jul
Additional comments:
1) I certainly hope the LISP compilers do NOT do the "optimization" the
APPLY* macro does. Consider what happens to
(APPLY* 'Foo Fred),
when Foo is a regular SUBR -- ie it will go to
(Foo Fred).
Ahh, but now the wily coder changes his mind, and realizes it should be
an NLAMBDA -- ie that the first argument should not be evaluated. However
it's the value of Fred, not the atom "Fred" itself, which should have been
passed in the example above. Need I go on?
2) You were right about DSETQ* -- your version definately saves those
cons-cells. I was thinking about an earlier version Dave and I discussed
which took another argument - which was a list - and reused those cells.
That, apparently, was never implemented. Sorry about the confusion.
3)wrt BACKQUOTE:
Yes, I agree there is no reason to have the additional arguments
for ,1 and the like -- that was just because that approach seemed easier;
and (without knowing about PPMacros) this seemed to print out prettier.
However, there are a few places where the other arg -- that arbitrary function
bit, was quite useful.
The file HEURS (ie {Rand-Ai}<GREINER.RLL>HEURS and now on {SAIL}HEURS[1,rdg])
uses that argument, via BACKQUOTEFN - an earlier incarnation of BACKQUOTE.
One relevant function is DefaultCodeGen, shown below
(DefaultCodeGen
[LAMBDA (phrase args)
(* edited: " 5-Mar-81 13:50")
(PROG (temp)
(RETURN (COND
((ATOM phrase)
phrase)
((SETQ temp (CodeGeneratingFn (CAR phrase)))
(APPLY* temp (CDR phrase)
(QUOTE DefaultCodeGen)
args))
[(GETD (SETQ temp (CAR phrase)))
|||| HERE |||| (BACKQUOTEFN phrase
|||| HERE |||| (FUNCTION (LAMBDA (term)
(DefaultCodeGen term args]
((Processp temp)
(APPLY* (GetValue temp (QUOTE LispFn)
(QUOTE (VERYSAFESLOT VERYSAFEUNIT)))
phrase
(QUOTE DefaultCodeGen)
args))
(T (Warning "Unable to figure the code to generate from " phrase
". (In "
(QUOTE DefaultCodeGen)
".)"])
Although it may not be obvious, this function will return essentially
the value of its first argument, phrase. Only certain key parts of this
s-expression need to be examined; the rest is simply returned as is.
Sounds like BACKQUOTE, don't it?
(Haven't you ever wanted to do something like this?)
Only here I want to "evaluate" that expression by recurring the
DefaultCodeGen call, rather than use BQ's EVAL.
So do I really have to duplicate all the code in BACKQUOTE to get this effect;
or do something silly like temporarily redefining the EVAL function, or ...
Anyway, the above code is a real example -- not just something kludged up to
attempt to convince you.
Should you buy this idea, it's not clear to me how you would want to print
out that stuff above.
Perhaps you would want to leave accessible the function which BQUOTE called,
which did take both arguments. This would allow us users to write our own
BQ-ish functions, which did or didn't evaluate various args, ...
4) Thanks for your suggestions about IOWAITDEMONs, and the like. It is
nice having so knowledgable a LISP wizard so close by.
.
5) Sure, if there's a bug in my code, or some obvious extension I hadn't
yet thought of, I'd like for people to tell me.
When else would people assault me, if my various pieces of code are released?
Thanks,
Russ
∂13-Sep-81 1626 GREINER at RAND-AI WHy some infinite loops are harmless:
To: rdg at SU-AI
Well - GetValue might have the same arguments twice, and this does NOT
lead to an infinite loop BECAUSE: that 2nd time thru might have been for
some KB update - which is "Acted on" only if the value has been changed.
Now the first time thru the value was already stored; so this second time
it's easy to retrieve the value. As the slot's ToCompute was not used, and
no new value was stored, there is no need to do any updates -- and hence
we will not need to request this u:s again (as it was only needed for
KB update purposes in the first place.)
Hence seeing two identical calls to GetValue on the stack is NOT intrinsically
bad, IF THAT CALL IS RELATED TO KB UPDATES. (Otherwise we is in truoble...)
Three identical calls is always trouble.
---
Things to do:
Put an ERRORSET within INTTY, around that TAILP function. Recall that that
function screws around with terminal I/O stuff, and so causes trouble
if ↑H-ed.
Consider making the GetValueSTK type of variables GLOBALVARS which are RESET
within each break. Hence the stack would only reflect current calls, as
desired. Also would be reset each ↑D, or each ↑ itself.
While fixing TRACER and FIND-INFINITE, use Warning equivalent rather than
ERROR - give the user a chance to say NO.
If XUTIL needs fixing anyway, change Dave's erroneous comment re: DRIBBLE.
-------